As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Information handling systems often use an array of storage resources, such as a Redundant Array of Independent Disks (RAID), for example, for storing information. Arrays of storage resources typically utilize multiple disks to perform input and output operations and can be structured to provide redundancy which may increase fault tolerance. Other advantages of arrays of storage resources may be increased data integrity, throughput and/or capacity. In operation, one or more storage resources disposed in an array of storage resources may appear to an operating system as a single logical storage unit or “logical unit.” Implementations of storage resource arrays can range from a few storage resources disposed in a server chassis, to hundreds of storage resources disposed in one or more separate storage enclosures.
Often, instead of using larger, monolithic storage systems, architectures allowing for the aggregation of smaller, modular storage systems to form a single storage entity, “a scaled storage array” (or storage array), are used. Such architectures may allow a user to start with a storage array of one or few storage systems and grow the array in capacity and performance over time based on need by adding additional storage systems. The storage systems that are part of a scaled storage array (or storage array) may be referred to as the storage nodes of the array. However, conventional approaches employing this architecture possess inefficiencies and do not scale well when numerous storage resources are included. For example, if a “READ” or “DATA IN” request is communicated to a storage array comprising multiple storage nodes, one of the storage nodes may receive and respond to the request. However, if all of the requested data is not present on the storage node, it may need to request the remaining data from the other storage nodes in the storage array. Often, such remaining data must be communicated over a data network to the original storage node receiving the READ request, then communicated again by the original storage node to the information handling system issuing the READ request. Thus, some data may be required to be communicated twice over a network. Accordingly, such conventional approach may lead to network congestion and latency of the READ operation. Also, because such congestion and latency generally increases significantly as the number of storage nodes in the storage array increases, the conventional approach may not scale well for storage arrays with numerous storage nodes.
An illustration of disadvantages of conventional approaches is depicted in FIGS. 1A and 1B. FIGS. 1A and 1B each illustrate a flow chart of a conventional method 100 for reading data from a plurality of storage nodes disposed in a storage array. In particular, as shown in FIGS. 1A and 1B, a host device may issue a command to read data from a storage array, wherein a portion of the data is stored in a first storage node, another portion of the data is stored in a second storage node, and yet another portion of the data is stored in a third storage node.
As depicted in FIGS. 1A and 1B, the first storage node which receives the request for data, provides a portion of the data stored locally on the storage node. The first storage node then issues its own request to one or more other storage nodes which contain a remainder of the requested data. The other storage nodes transfer the data to the original storage node, which then transfers the data back to the host, to complete transfer of all data requested in the read operation.
For example, at step 102 of FIG. 1A, a host device may issue a READ command to the first storage node. At step 104, the first storage node may communicate to the host device the portion of the data residing on the first storage node. At step 106, the first storage node may issue its own READ command to a second storage node. In response, at step 108, the second storage node may communicate to the first storage node the portion of the data residing on the second storage node, after which, at step 110, the second storage node may communicate to the first storage node a STATUS message to indicate completion of the data transfer from the second storage node. At step 112, the first storage node may communicate to the host device the portion of the data that was stored on the second storage node.
Similarly, at step 114, the first storage node may issue a READ command to a third storage node. At step 116, the third storage node may communicate to the first storage node the portion of data residing on the third storage node, and then communicate to the first storage node a STATUS message to indicate the completion of the data transfer at step 118. At step 120, the first storage node may communicate to the host device the portion of the data that was stored on the third storage node. At step 122, the first storage node may communicate to the host device a status message to indicate completion of the transfer of the requested data. After completion of step 122, method 100 may end.
While method 100 depicted in FIGS. 1A and 1B may successfully communicate data from a storage array to a host device, method 100 may suffer from numerous drawbacks. For example, because data read from each of the second and third storage nodes must be communicated over a network twice (e.g., for the portion of the data stored on the second storage node: once from the second storage node to the first storage node as depicted in step 108, then from the first storage node to the host device at step 112), the method 100 may lead to network congestion and latency of the READ operation. Also, because such congestion and latency increases significantly as the size of a storage array increases, the conventional approach may not scale well for storage arrays with numerous storage nodes.